The modern aircraft cockpits include a set of interactive display devices for displaying, controlling and modifying all the parameters necessary to the piloting, navigation and more generally the accomplishment of the mission. The number of parameters to be managed is considerable and there are a multitude of possible graphical representations of these parameters.
The aeronautical software application is produced on a computer development workbench in a “PC” type computer environment. Currently, for many aeronautical applications, the definition of the human-machine interfaces, or “HMI”, is governed by an aeronautical standard: ARINC 661. This standard specifies the interface between the display subsystem of a cockpit, or “CDS”, standing for “Cockpit Display System”, and the other avionics system equipment. It notably defines two external interfaces between the CDS and the systems of the aeroplane which are:                The interface between the avionics equipment systems called user systems and the graphical display system or Client-server;        The system behaviour of the displayable graphical elements.        
The graphical part of the embedded HMIs of the aeronautical field are described in Definition Files (DF). The DFs describe the “widgets” that make up the HMI independently of their behaviour. A widget is a software unit associated with a graphical representation and a behaviour enabling the crew either to receive information, or, by means of a human-machine interface, to give instructions. From a software viewpoint, each widget offers technical interfaces of “click down”, “click up”, “change colour” and other such types, allowing for the production of events and for the modification of this widget. Their behaviour is coded in an application called “User Application” or “UA” which interacts with the widgets of the HMI through an ARINC 661 standardized exchange protocol. Thus, the HMI represents the state of the functional core of the UA.
The symbolic operation of the reciprocal exchanges between the User Application and the graphical server is represented in FIG. 1.
The complete process involved in developing an aeronautical software application is represented in FIG. 2 in the form of an uppercase V. This process comprises six steps which are:
Specification step;
Design step;
Coding step;
Verification or debugging step;
Functional testing step;
Final verification step.
Technically, the computer development workbench must satisfy the following main requirements:                To design, implement and use a unified method for designing and developing HMIs of ARINC 661 type so as to:                    Reduce the recurrent development costs associated with different and non-unified development methods;            Best re-use the HMI components.                        To formalize the interfaces between the functional core of the UA and the HMI in order to:                    Reduce the impacts of changes to the client specification or to the functional core on the HMI in terms of design and code.                        To design, implement and use a development platform or workbench offering the unified design and development capabilities of the ARINC 661 HMIs in order to:                    Deploy unified services;            Unify the method by the use of the workbench which implements it;            Reduce the design and manual coding activities.                        
Currently, the development of the aeronautical software applications involves the application of a conventional development process using manual code with different design methods depending on the projects. This development is represented in FIG. 3. It comprises three parts framed by dotted lines. The first frame contains the upstream specifications step, the second frame contains the functionalities of the development workbench, finally the third frame contains the implementation in the CDS.
Traditionally, the production by the development workbench of an avionics interactive graphical system is completed in two steps:                Creation of the “static” aspect of the page using a graphics workbench, which can be used to place widgets on an HMI page and to define its initialization properties;        Development in manual coding of the software of the processing logic, so that the content of the page can be modified according to incoming events.        
The ARINC 661 HMI development activity consists in:                Constructing the graphical HMI, that is to say using and organizing the ARINC 661 widgets according to the requirements of the upstream specification by conforming to the characteristics of the ARINC 661 widgets referenced in the manual code;        Producing the Definition File.        
The manual coding activity consists in:                Implementing the requirements of the upstream specification in logic function terms;        Producing the ARINC 661 command blocks corresponding to the state of the functional core by conforming to the ARINC 661 standard and to the characteristics of the ARINC 661 widgets of the “Definition File”;        Consuming the notifications of the ARINC 661 widgets of the “Definition File” by conforming to the ARINC 661 standard and to the characteristics of the ARINC 661 widgets of the Definition File;        Transmitting the events to the functional core.        
The direct consequences of this design method are that a modification of the requirements of the upstream specification relating to the functionality of the HMI directly impacts on the manual code with a strong risk of inconsistency with the “Definition File” and a modification of the requirements of the upstream specification relating to the graphics of the HMI impacts directly on the Definition File with a strong risk of inconsistency with the functionality of the HMI.
Ultimately, the drawbacks of the existing solutions are as follows:                Changes to the graphical HMI directly impact on the design and the code of the interface between the HMI and the functional core of the UA and therefore entail additional activity on the descending part of the V of the development cycle as represented in FIG. 2;        Changes to the interfaces of the functional core of the UA directly impact on the design and the code of the interface between the graphical HMI and the functional core and therefore entail additional activity on the descending part of the V of the development cycle;        The coding activities entail additional test activity on the ascending part of the V of the development cycle;        The ARINC 661 HMI developments are carried out according to methods specific to each project. There is no unified method and formalized structure for the ARINC 661 HMI developments;        The complexity and the volume of the design and of the manual code cause HMI maintenance problems. The code is often modified directly and the design is modified a posteriori by reverse engineering.        